Software developers wish to provide programmatic functionality over the Internet through the creation of web services. These web services provide some valuable technology in which the developer has expertise. Web services are often deployed in such a way that the user of the web service has a direct connection with a server.
One problem that arises from this process of exposing the web services for consumption over the web by an end user application is that in order to protect unauthorized access of these web services over the Internet, the web services must somehow incorporate authentication and authorization of users and other security measures. When a user wishes to use a web service on a server, the server usually needs to ensure that the user is authorized to have access. This authentication of the user is typically done by sending the user's name and password to the server which then verifies the given data before granting access. Since the authentication data is sensitive, it is desirable to be sent over a secured channel, such as the hypertext transfer protocol over secure socket layer (https), which encrypts the data. Using a secured channel is safer but slower than an unsecured channel since it requires the extra encryption/decryption steps.
An alternative solution is to have the user log into the web service once by sending the user name and password over the secure channel and in return the user will receive a unique authentication identifier (ID) over the secured channel. Sometimes an authentication ID is called a session ID. However, there is a distinction between a session ID that refers to a locked communication between a client and a server and a session ID that refers to the fact that authentication has occurred. Thus, the term authentication ID will be used in this specification.
Successive calls to the web service are then made over an unsecured channel with the authentication ID to identify the user. Since the user name and password are not sent during the successive calls, the calls no longer needs to be done over a secure channel. The calls can be sent over an unencrypted channel, such as the hypertext transfer protocol (http). This will improve performance as well as limit the number of times that the user name and password are sent. When the server receives a web service call, it will authorize the user by verifying that the authentication ID is valid at that point in time.
This use of an authentication ID is only partially acceptable since the user name and password are safe as they are passed over the secure channel once and the user can still be authenticated for access to web services using the authentication ID. The problem is that since the web service calls are not done over a secured channel, the authentication ID could be compromised. Anyone who is observing the unsecured channel could note the authentication ID as it is used in the web service calls. They could then reuse this authentication ID and gain unauthorized access to the web service.
One adaptation to the use of an authentication ID is to have the authentication ID time out after a certain period of time. Once an authentication ID has expired, anyone who has obtained it with or without authorization will no longer be able to use it and the authorized user will have to log on again and receive a new authentication ID.
While the time-out of an authentication ID solution is better than no solution, there is still the problem that a misuse of a web service may occur for a limited time. It is desirable to provide means for providing better security when providing services over a network.